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ABSTRACT 

Software testing uses wide range of different tools to enhance 
the complicated process of defining quality of the system 
under test. Formal Concept Analysis (FCA) provides us 
with algorithms of deriving formal ontology from a set of 
objects and their attributes. With the use of FCA we can 
considerably improve the efficiency of test case derivation. 
Moreover, an FCA-based machine learning system supports 
the analysis of regression testing results. 

1. INTRODUCTION 

Software testing aims at understanding the risks of software 
implementation and providing proper quality of the system 
under test. One of fundamental problems is that testing 
under all possible combinations of inputs is not feasible. 
This holds for functional testing, while non-functional as¬ 
pects (performance, compatibility, etc.) are left apart. For 
business critical applications black-box testing is a widely- 
used approach. It examines the functionality of a system 
under test without dealing with its implementation. It is 
important to notice that static testing involves verification, 
while dynamic testing involves validation. 

One of the biggest challenges in black-box dynamic testing 
is choosing the proper approach to enumerate all possible 
cases. Domain testing helps quality assurance engineer to 
define classes of input values, that are crucial to test. The 
naive way is just to check for possible combinations of such 
parameters, and it immediately leads to exponential com¬ 
plexity. Even in the case of 6 boolean parameters an expert 
has to check 64 combinations. 

A possible solution is to generate test-cases in manual way. 
A software test engineer considers all possible cases ordered 
in a certain way. The main risk is to lose some information 
behind the cases. Actually, it could be rather exhausting to 
cover all possibilities for a large number of parameters and 


not to skip some scenarios. 

A popular alternative way is pairwise testing J2], or its gen¬ 
eralization, n-wise testing. We define parameters and do¬ 
mains, and pass them like a model into a black-box algo¬ 
rithm I], which gives us a set of test-cases satisfying a cer¬ 
tain condition (for each pair of input parameters all possible 
discrete combinations of those parameters are tested). In 
general case it can produce different cases in different runs, 
while it can be fixed by passing a random seed to it. The 
main advantage of the approach is its insensitivity to pa¬ 
rameter values. However, it can be a rather computationally 
demanding task. 

For quality assurance engineers it is sufficient to have knowl¬ 
edge about possible behavior of the program. Usually, there 
are dependencies between input parameters. A natural form 
to express such dependencies in mathematical terms is impli¬ 
cation, a statement of the form: ‘if ..., then ...’. The ‘if’-part 
is called premise, and the ‘then’ is called conclusion. Con¬ 
sideration of parameter’s interdependence can decrease the 
complexity of result test-cases in terms of their quantity, by 
excluding some of possible parameter combinations. 

Proposed approach to test-case generation is focused on im¬ 
plications. We use an approach based on Formal Concept 
Analysis (FCA) [5], FCA provides software engineers with a 
tool for exploring the domain of interest in semi-automatic 
way The algorithm outputs sound and complete description 
of the problem, but it is still highly dependent on the accu¬ 
racy of expert’s answers. Surveys on FCA techniques and 
applications can be found in 11 . FCA-based approaches 
have already been applied in software engineering, e.g., for 
inference of class hierarchies 12], class design |l3], refactor¬ 
ing 14). Another application of FCA technique is analysis of 
object-oriented approach for a given system 15]. The ques¬ 
tions of mapping lines of source code to the functionality 
from requirements is of crucial importance for big systems 



The rest of the paper is organized as follows: in Section 2 
we introduce basic notions of Formal Concept Analysis. In 
Section 3 we focus on the procedure of attribute exploration. 
Section 4 provides example of attribute exploration in the 
field of positive integers. We make conclusions in Section 5. 


2. FORMAL CONCEPT ANALYSIS 


Formal Concept Analysis [5] (FCA) provides mathematical 
technique for deriving applied ontologies from data. FCA 
relies on lattice and order theories :3 Numerous applications 
are found in the field of machine learning, data mining, text 
mining and biology, see j 11. ?]. 

2.1 Main Definitions 

Definition 1. A formal context A" is a triple K := ( G , M , I), 
where G denotes a set of objects, M is a set of attributes, 
and I C G x M is a binary relation between G and M. 


It can be interpreted in the following way: for objects in G 
there exists a description in terms of attributes in M, and 
relation / reflects that an object has an attribute: ( g , m) £ 
I <==> object g possesses m. 

An example of a formal context is provided below: 



Objects: 

Attributes: 

1 - equilateral triangle 

a - 3 vertices, 

2 - right triange, 

b - 4 vertices, 

3 - rectangle, 

c - has a right angle, 

4 - square, 

d all sides are equal 


Traditionally, notation (•)' is used instead of ip and if. (■)" 
stands both for tpoif and if cup (depending on the argument). 
For arbitrary A C G, B C M 

A' = f {m £ M | glm for all g £ A}, 

B' = f {g £ G | glm for all m £ B}. 


Definition 3. (Formal) concept is a pair (A, B): AC.G, 

B C M, A' = B, B' = A. 

In the example with geometric figures a pair ({3,4}, { 6 , c}) is 
a formal concept. For a formal context (G, M, I), A , Ai, A 2 C 
G - set of objects, B C M - set of attributes, the following 
statements hold for operation (■)’: 

1. Ai C A 2 => A' 2 C A[ 

2. Ai C A 2 => A" C A 2 
3 .AC A" 

4. A'" = A' and A"" = A" 

5. (A 1 U A 2 )' = A[ nd) 

6 . 

Definition f. Closure operator on set G is a mapping 7 : V{G) 
V(G), which maps every X C G to closure 7 A' C G, under 
the following conditions: 

1 . 77 A' = 7 A” ( idempotence) 

2. A' C 7 X ( ext-ensivity ) 

3. X C Y => 7 X C 7 Y ( monotonicity ) 


For a given context two following mappings are considered: 

ip: 2° —> 2 m p(A) = f {m £ M \ glm for all g £ A}, 
if: 2 m 2° if(B) = f {g £ G \ glm for all m £ B}. 

For all A U A 2 C G, B 1 ,B 2 C M 

1 . A\ C A 2 =4> p(A2) C p[A\) 

2. Bi C B 2 => if(B 2 ) C if{B{) 

3. A\ C iftp(Ai) andBi C ipif(Bi) 

Definition 2. Mappings p and if, satisfying properties 1- 
3 above, define a Galois connection between ( 2 G ,C) and 
(2 m , C), which means: <p(A) C B 77 if(B) C A 


Definition 5. Implication A —> B, where A, B C M, takes 
place if A' C B 1 , in other words if each object having A also 
has all attributes from B. 

Implications comply with Armstrong axioms: 


———-( 2 ) 

A'UZ^f 1 

X^Y,YUZ^W 

X u z w 1 ’ 

3. LATTICE DIAGRAMS 

One of advantages of building lattices of formal concepts is 
to get effective navigation from more general concepts to 
more specific. For example, the line diagram for context 
with figures from previous section is shown in Fig. 1. That 
property could be beneficial in two ways: regression testing, 
system description. 











Figure 3: Test run: line diagram of Concepts with 
failed=True highlighted 


Figure 1: Line diagram for context with geometric 
figures 



Figure 2: Test run: Line diagram of all tests 

First of all, for the context of regression testing it imple¬ 
ments the algorithm to determine the classes of tests that 
fail. It could be considered in the following way. Let us 
define set of attributes for all tests that are being run. 


G \ M 

failed 

https 

login 

messages 

1 

X 

X 

X 


2 


X 


X 

3 

X 


X 


4 




X 


Then we can view the line diagram of all the tests during 
the run. See Fig. 2. The most interesting formal concepts 
are those with attribute “failed=True”, since the simplified 
result could be treated as either success or fail. Now we 
can notice that “messages” part is ok, while login module 
breaks totally, and there is one problem with “https”. The 
convenient strategy for making such meta-reports is to filter 
the set of all tests which have “failed=True” flag. Then we 


can build concept lattice for obtained filtered formal context. 
Moreover, we could build just the top part of concept lattice, 
since it will have most general attributes. 

The second important application of formal concepts in big 
systems is analysis of dependent features. Since modern 
software development process usually is organized in agile 
manner, it is important to view the effect of developed fea¬ 
tures on the overall system, and examine connected compo¬ 
nents. ft could be fruitful to use test cases from features with 
common functionality. To track such features and to have 
user-friendly navigation we can use FCA-based techniques. 
We need to have the list of features and set of tags as gen¬ 
eral components description. A small example is provided 
below. We can build formal concept lattice for the context 
describing the features. Then we can search obtained graph, 
finding not only features with the same set of tags, but also 
more general and more specific ones. The initial lattice is 
depicted in Fig. 4. If we want to analyze the feature with 
tags “https” and “login” we see that it forms formal concept 
({fl,f3,f5},{}) 


G \ M 

billing 

https 

login 

messages static 

fl 

X 

X 

X 


f2 


X 


X 

f3 

X 

X 

X 

X 

f4 



X 

X 

f5 


X 

X 

X 


4. FEATURE IMPACT ANALYSIS 

One of the most important steps of testing software is to 
determine the functionality that would be changed. Usually, 
all activities concerning the development process are stored 
in issue trackers. It is important to reuse the experience 
of previous features while developing new functionality. We 
can think of two dimensions of analysis of related features. 
Firstly, issue trackers typically provide the possibility to link 
tickets and in this way we can draw graph of similar features. 
Secondly, we can benefit from tags that are used to mark 
system parts. So, example from the previous section could 
be studied in alternative way: we can browse features to find 





















the closest one in terms of functional units. We can find out 
which cases were obligatory in this case and simplify test- 
case design process. 



Figure 4: Features description 



Figure 5: Features description: concept with “https” 
and “login” 


5. ATTRIBUTE EXPLORATION 

Attribute exploration is a well-known FCA-based discovery 
technique. The main idea is to explore the implications in 
the object domain in a semi-automatic manner. According 
to Attribute Exploration a domain expert answers specific 
questions about possible implicational dependencies in his 
domain. Questions are provided in the form of attribute im¬ 
plications, asking whether they are true or false. If the an¬ 
swer is true, the implication is added to the knowledge base. 
In the case of answer “false”, the expert is asked to provide 
a counterexample violating the proposed dependency. 

In other words, the exploration algorithm explores all possi¬ 
ble combinations of a given attribute set. It is typical that 
objects in this field of knowledge are too difficult to enumer¬ 
ate them. So the algorithm starts with a set of examples, 
then it computes canonical base of implications for the pro¬ 
vided formal context. Then the domain expert is asked if 
the computed implications are valid. If it is true, than the 
existing context represents all possible combinations in the 
domain. Otherwise, the expert has to provide a counterex¬ 
ample to implications, which should be added to the context 
as new objects, and then the implication base is recomputed. 

The general strategy is quite intuitive: we start exploring 
the domain with some knowledge of typical examples and 
implications. To extend the knowledge base we either add 
an implication, or provide another example that violates cur¬ 
rently studied implication. The main advantage of this ap¬ 
proach is that generation of dependencies (implications) is 
performed algorithmically. 


Algorithm 1 Next Closure(A, M, C) 

Input: Closure operator X H> C{X) on attribute set M 
and subset ACM. 

Output: lectically next closed itemset A. 
for all m £ M in reverse order do 
if m £ A then 
A := A \ {m} 

else 

B := C(A U {m}) 

if B \ A does not contain elemens < m then 
return B 

return T 
























Algorithm 2 Attribute Exploration 
Input: A subcontext (E, M, J = I n E x M) of (G, M, /), 
possibly empty. 

Input: Interactive: confirm that A = B" in a formal con¬ 
text (G, M, I), M finite, or give an object showing that 
A ^ B". 

Output: The canonical base £ of (G, M, I) and a possibly 
enlarged subcontext (E, M, J = IClE x M ) with the same 
canonical base. 

£ :=0 
A := 0 

while A M do 

while A ^ A JJ do 

if A JJ = A 11 then 

£ := £ U {A —>• A JJ } 
exit while 

else 

extend E by some object g £ A 1 \ A JJI 
A := NextClosure(A, M, £) 
return £, (E, M, J) 


6 . PRACTICAL EXAMPLES 
6.1 Numbers 

Let us consider the domain of natural numbers 6 . As a set 
of possible attributes we can consider the following ones: 
even (2*n), odd (2*n+l), divisible_by_three (3*n), prime 
(has no positive divisors other than 1 and itself), factorial 
(is a factorial of a positive number). We start from the 
empty set of objects. The canonical base for such context is 
0 — > M. So we get a question: 

=> even, factorial, dividedJby Ahree, odd,prime 
Is the following implication valid? 

Obviously, not all numbers have all attributes. At least we 
can consider number 2, which is even, factorial, prime. We 
add 2 to our context and the base is recomputed. 


G \ M 

even 

factorial 

divided by three 

odd 

prime 

2 

X 

X 



X 


=> even, factorial,prime 
Is the following implication valid? 

Now we can consider number 5, which is prime, odd 


G \ M 

even 

factorial 

divided by three 

odd 

prime 

2 

X 

X 



X 

5 




X 

X 


=> prime 

Is the following implication valid? 

Now we are about to either say that all numbers are prime, 
or provide a non-prime number, e.g. 6 


G \ M 

even 

factorial 

divided by three 

odd 

prime 

2 

X 

X 



X 

5 




X 

X 

6 

X 

X 

X 




factorial => even 

Is the following implication valid? 

Now we have both 2 and 6, which are simultaneously even 
and factorial. There is a counterexample, we should find a 
number that is factorial, but not even, which is 1. 


G \ M 

even 

factorial 

divided by three 

odd 

prime 

2 

X 

X 



X 

5 




X 

X 

6 

X 

X 

X 



1 


X 


X 

X 


odd => prime 

Is the following implication valid? 
No, it does not hold for number 9. 


G \ M 

even 

factorial 

divided by three 

odd 

prime 

2 

X 

X 



X 

5 




X 

X 

6 

X 

X 

X 



1 


X 


X 

X 

9 



X 

X 



factorial, odd => prime 

Is the following implication valid? 

We have the only number 1 which is factorial and odd, and 
it is also prime. 

factorial, dividedJbyJthree => even 
Is the following implication valid? 

Now we have to recall what is implication? The only case 
where implication does not hold is when premise is true 
and conclusion is false. The least factorial which is di- 
vided_by_three is 6, which is already even. 
prime, divided_by_three => even, factorial, odd 
Is the following implication valid? 

We have number 3, which is just odd. 


G \ M 

even 

factorial 

divided by three 

odd 

prime 

2 

X 

X 



X 

5 




X 

X 

6 

X 

X 

X 



1 


X 


X 

X 

9 



X 

X 


3 



X 

X 

X 


prime, dividedJby_three => odd 
Is the following implication valid? 

The only prime that is dividecLbyuthree is three itself, so it 
is true, even => factorial 
Is the following implication valid? 

Not all even numbers are factorials, e.g. 8. 















































G \ M 

even 

factorial 

divided by three 

odd 

prime 

2 

X 

X 



X 

5 




X 

X 

6 

X 

X 

X 



1 


X 


X 

X 

9 



X 

X 


3 



X 

X 

X 

8 

X 






6.2 Numbers: model-based 

We can consider the same problem and use pairwise testing. 
One of known tools for this is PICT, pairwise testing tool 
by Microsoft. The initial model is quite simple. 

• Event: 1, 0 

• Factorial: 1, 0 

• Divs3: 1, 0 


even, odd => factorial,prime, divided_by_three 
Is the following implication valid? 

We do not have numbers which are both even and odd. 
even, dividedJyy-three => factorial 
Is the following implication valid? 

We have number 12, which is even and divided_by_three, 
but it is not a factorial. 


G \ M 

even 

factorial 

divided by three 

odd 

prime 

2 

X 

X 



X 

5 




X 

X 

6 

X 

X 

X 



1 


X 


X 

X 

9 



X 

X 


3 



X 

X 

X 

8 

X 





12 

X 


X 




• Odd: 1, 0 

• Prime: 1, 0 


The result of pairwise generation is shown in table below: 


Even 

Factorial 

Divs3 

Odd 

Prime 

1 

1 

0 

0 

1 

0 

0 

1 

1 

0 

1 

0 

1 

1 

1 

0 

1 

0 

1 

0 

1 

0 

1 

0 

0 

0 

1 

1 

0 

1 

0 

0 

0 

0 

0 


To get the results as in the previous section, we have to 
modify the input model in the following way: 


even, prime => factorial 

Is the following implication valid? 

The only even prime number is 2. So, the exploration pro¬ 
cess is over. 

The final context: 


G \ M 

even 

factorial 

divided by three 

odd 

prime 

1 


X 


X 

X 

2 

X 

X 



X 

3 



X 

X 

X 

5 




X 

X 

6 

X 

X 

X 



8 

X 





9 



X 

X 


12 

X 


X 




The set of implications: 

• factorial, odd —> prime 

• factorial, divided-by-three —t even 

• prime, dividedjyycthree —> odd 

• even, odd —> factorial,prime, dividedJby-three 

• even, prime —t factorial 


1. Parameters: 

• Event: 1, 0 

• Factorial: 1, 0 

• Divs3: 1, 0 

• Odd: 1, 0 

• Prime: 1, 0 

• Result: 12, 9, 6, 3, 2, 1 

2. Implications 

• IF [Even] = 1 THEN [Odd] = 0 ELSE [Odd] = 1; 

• IF [Odd] = 1 AND [Factorial] = 1 THEN [Result] 

= 1 ; 

• IF [Even] = 1 AND [Prime] = 1 THEN [Result] 
= 2 ; 

• IF [Divs3] = 1 AND [Prime] = 1 THEN [Result] 
= 3 ; 

• IF [Divs3] = 1 AND [Even] = 1 THEN [Result] 
IN 6, 12; 

• IF [Divs3] = 1 AND [Odd] = 1 AND [Prime] = 0 
THEN [Result] =9; 

• IF [Even] = 1 AND [Factorial] = 1 AND [Divs3] 
= 0 THEN [Result] = 2; 

3. Data-specific dependencies 

• IF [Result] = 1 THEN [Even] = 0 AND [Facto¬ 
rial] = 1 AND [Divs3] = 0 AND [Odd] = 1 AND 
[Prime] = 1; 






• IF [Result] = 2 THEN [Even] = 1 AND [Facto¬ 
rial] = 1 AND [Divs3] = 0 AND [Odd] = 0 AND 
[Prime] = 1; 


• IF [Result] = 3 THEN [Even] = 0 AND [Facto¬ 
rial] = 0 AND [Divs3] = 1 AND [Odd] = 1 AND 
[Prime] = 1; 


• IF [Result] = 6 THEN [Even] = 1 AND [Facto¬ 
rial] = 1 AND [Divs3] = 1 AND [Odd] = 0 AND 
[Prime] = 0; 


• IF [Result] = 9 THEN [Even] = 0 AND [Facto¬ 
rial] = 0 AND [Divs3] = 1 AND [Odd] = 1 AND 
[Prime] = 0; 


• IF [Result] = 12 THEN [Even] = 1 AND [Facto¬ 
rial] = 0 AND [Divs3] = 1 AND [Odd] = 0 AND 
[Prime] = 0; 


For such model PICT outputs the following cases: 


Even 

Factorial 

Divs3 

Odd 

Prime 

Result 

0 

0 

1 

1 

1 

3 

1 

1 

1 

0 

0 

6 

0 

0 

1 

1 

0 

9 

1 

0 

1 

0 

0 

12 

1 

1 

0 

0 

1 

2 

0 

1 

0 

1 

1 

1 


6.3 Banners with geotargeting 

One of the most popular forms of advertising in the In¬ 
ternet is contextual advertisement. The key point is that 
companies pay for the click on their sites, but not for the 
shows, so the targeting part gains more importance. One 
of most-widely used features is geotargeting, i.e., defining 
in which regions the banner could be shown. Usually, re¬ 
gions are treated like a tree and if banner targets at some 
region, then it could be shown in it, and all it subregions. 
The possible sources for defining region: query argument, 
search query, ip address. Attributes with binary domains: 
M = {IsQueryPresent(IQP), 

IsQueryValid(IQV ), IsSqPresent(ISP ), IsSqValid{ISV), 
IsIpPresent(IIP ), IsIpValid(IIV), 

User Region =— Banner Region(=), 

User Region < Banner Region(<), 

User Region > Banner Region(>), 

IsBannerShown(IBS)} 






Implication list: 

1. IF IQV THEN IQP 

2. IF ISV THEN ISP 

3. IF IIV THEN IIP 

4. IF = THEN IBS, not <, not > 

5. IF < THEN IBS, not =, not > 

6. IF IBS THEN not > 

7. IF not IQP THEN not IQV 

8. IF not ISP THEN not ISV 

9. IF not IIP THEN not IIV 

10. IF not IIV, not ISV, not IQV THEN not =, not <, 
not >, not IBS 

11. IF not <, not = THEN not IBS 

12. IF not >, IQV, IQP THEN IBS 

13. IF not >, ISV, ISP THEN IBS 

14. IF not >, IIV, IIP THEN IBS 

15. IF not >, not ISV, not IQV, IBS THEN IIV 

16. IF not >, not ISV, not IIV, IBS THEN IQV 

17. IF not >, not IIV, not IQV, IBS THEN ISV 

18. IF not >, not =, IBS THEN < 


7. PLUG-IN SETUP 

The most important advantage of the proposed approach is 
the plug-in design. It can be easily incorporated in existing 
process of test-case generation. For manual test-case design 
one can develop test-cases in proposed system. Moreover, 
the step of implication extraction could be postponed up 
to the review of obtained cases. It is important to notice 
that Attribute Exploration is a good technique to extract 
dependencies that could be formulated as requirements for 
the system under test. For the case of automatic test case 
generation, extraction of dependencies could eliminate the 
step of test debug and replace it with review of obtained 
implications and the model of the system under test. Also 
the proposed technique is applicable to verify the correctness 
of defining type of model, precisely wiseness of it. Since big 
values of n in n-wise modeling impose more test cases and 
it results in the growing time of test run execution. 

8. CONCLUSION 

Formal Concept Analysis provides us with useful framework 
for software testing tasks. It is especially beneficial in re¬ 
gression testing meta report construction, feature naviga¬ 
tion, test case analysis and derivation. It unites best prac¬ 
tices of manual development and automatic generation of 
test scenarios. It provides sound and complete description 
of the investigated domain, based on expert knowledge. The 
output of the system consists of two main parts: the descrip¬ 
tion of typical objects in the domain, and interdependence 
between parameters in terms of implications. An important 
advantage of proposed technique is extensibility. If we add a 
new attribute, we can just copy the previous examples into 
new formal context, assuming that new attribute is absent 
for all objects and proceed with the procedure of attribute 
exploration. It holds even for the very start of procedure. 
We can start with non-empty set of objects and implications 
simultaneously. The described algorithm could be used as a 
standalone solution for the test case design, as well as, tool 
to get exiting dependencies in the domain. The obtained 
implications could be valuable in pairwise testing to adjust 
the model description. 


19. IF not >, not <, IBS THEN = 

20. IF not IBS THEN not =, not < 

21. IF not IBS, not <, not =, IQV, IQP THEN > 

22. IF not IBS, not <, not =, ISV, ISP THEN > 

23. IF not IBS, not <, not =, IIV, IIPTHEN > 

24. IF not IBS, not <, not =, >, not IQV, not ISVTHEN 
IIV, IIP 

25. IF not IBS, not <, not =, >, not IIV, not IQVTHEN 
ISV, ISP 

26. IF not IBS, not <, not =, > not IIV, not ISVTHEN 
IQV, IQP 

27. IF not IBS, not >, not =, not <THEN not IQV, not 
ISV, not IIV 


However, we should admit that the current approach is lim¬ 
ited in terms of attribute description. For now, it is highly 
dependent on the boolean nature of attributes. One of the 
main directions of future work is to work with descriptions 
of general form by means of patterns structures [4, 10 , an 
extension of FCA. 
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